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Abstract.  Informal  and  casual  consideration  of  Intended  Use  in  Modeling  and 
Simulation  practice  can  pose  programmatic  risks  in  acquisition,  especially  in  system- 
of-system  contexts,  such  as  the  Ballistic  Missile  Defense  System.  Leveraging  lessons 
learned  from  intense  reliance  on  system-of-system  simulations,  the  Missile  Defense 
Agency  is  formalizing  specification  of  Intended  Uses  to  mitigate  those  risks  and  to 
improve  effectiveness  and  affordability  of  the  Agency’s  diverse  simulations. 

Introduction 

The  objective  of  this  article  is  to  present  an  approach  in  de¬ 
velopment  by  the  Missile  Defense  Agency  (MDA)  for  specifying 
the  Intended  Use  (lU)  in  Modeling  and  Simulation  (M&S)  applied 
in  a  system-of-systems  (SoS)  context.  The  MDAs  mission  is  to 
develop,  test,  and  field  an  integrated,  layered.  Ballistic  Mis¬ 
sile  Defense  System  (BMDS)  to  defend  the  United  States,  its 
deployed  forces,  allies,  and  friends  against  all  ranges  of  enemy 
ballistic  missiles  in  all  phases  of  flight.  The  BMDS  is  a  SoS. 

Many  practical  and  legal  constraints  force  SoS  acquisition 
organizations  like  MDA  to  depend  on  M&S  for  diverse  needs, 
such  as  assessment,  training,  exercise  and  concept  develop¬ 
ment  [1].  Typically,  SoS  M&S  relies  heavily  on  the  compositions 
(sometimes  called  “federations”)  of  legacy  M&S  independently 
developed  for  the  constituent  systems  of  the  SoS.  Disparities 
among  the  original  lUs  of  the  constituent  systems’  simulations 
complicate  or  even  confound  a  SoS  M&S  lU,  which  itself  usually 
differs  from  the  constituent  simulations’  original  I  Us. 

Suitability  of  BMDS  M&S  for  an  I U  is  at  the  core  of  an  Ac¬ 
creditation  process  [2]  incorporating  formal  analysis  of  risks 
to  acquisition  and  warfighting  from  using  a  specific  simulation 
supporting  essential  decisions,  such  as  deployment.  Thus,  MDA 
developed  a  SoS  M&S  lU  approach  to  improve  outcomes  of  its 
BMDS  M&S  systems  engineering  and  accreditation  processes. 
MDAs  SoS  M&S  lU  approach  has  features  and  implications  use¬ 
ful  for  SoS  M&S  engineering  in  other  M&S-reliant  domains,  such 
as  Command,  Control,  Communications,  Computers,  Intelligence, 
Surveillance  and  Reconnaissance  (C4ISR)  and  space  exploration. 

In  the  following  sections,  we  consider  first  what  M&S  lU  really 
means,  and  how  widespread  usage  of  the  term  without  any  com¬ 
mon  definition  creates  practical  difficulties— especially  for  SoS 
M&S.  We  present  our  lessons  learned  about  programmatic  risks 
that  M&S  lU  misspecification  (or  outright  ignorance)  can  create. 


From  those  lessons  emerged  MDAs  new  practice  for  BMDS 
M&S  lU  specification,  which  focuses  on  the  needs  of  the  stake¬ 
holder  analyst  as  a  consumer  of  M&S.  A  subsequent  case  study 
shows  the  implications  of  ignoring  a  SoS  M&S  lU  specification. 
Finally,  we  present  our  vision  for  migrating  MDAs  BMDS  M&S  lU 
specification  to  a  model-centric  systems  engineering  environment 
that  can  increase  the  reliability  and  timeliness  of  BMDS  M&S 
development  and  use. 

“Everybody  Knows  What  M&S  ‘Intended  Use’  Means... Right?” 

Numerous  M&S  authorities  describe  the  Importance  of  speci¬ 
fying  an  M&S  lU  but  neglect  to  define  “lU”  explicitly  (e.g.,  [3], 

[4]).  For  example,  [5]  presents  the  following  circular  definition: 
“An  M&S  application’s  Intended  Use  refers  to  the  explicitly  and 
clearly  defined  purpose  for  which  the  application  is  intended  for 
use.”  Representative  of  DoD  interest  in  M&S  accreditation  for  af¬ 
fordable  reuse,  MIL- STD  3022,  “Documentation  of  Verification, 
Validation  and  Accreditation  (VV&A)  for  Models  and  Simula¬ 
tions,”  also  does  not  define  “lU”  but  does  require  documentation 
of  “the  problem  to  be  addressed  by  the  M&S  and  its  associated 
data,  including  the  system  or  process  being  represented  and  the 
role  it  plays  in  the  overall  program”  [6]. 

Notwithstanding  arguments  about  inadequacies  of  M&S  re¬ 
quirements  engineering,  we  observe  that  effective  practitioners 
invariably  develop  new  M&S  with  one  or  more  definite  purposes 
in  mind.  Thus,  for  new  M&S  development,  an  unambiguous,  test¬ 
able  definition  of  M&S  “lU”  might  seem  unnecessary.  Many  au¬ 
thorities  thus  imply  that  M&S  “lU”  is  an  important,  essential  but 
undefinable  concept  akin  to  “point,”  “line,”  or  “plane”  in  geometry.^ 

Working  in  a  SoS  M&S  enterprise  emphasizing  affordability 
and  simulation  asset  reuse,  we  drew  from  our  “lessons  learned” 
the  conclusion  that  M&S  “lU”  must  be  formally  defined  so  that 
lU  specifications  may  be  compared  and  tested  for  clarity,  com¬ 
pleteness  and  compatibility.  The  following  review  of  those  les¬ 
sons  learned  and  programmatic  risks  we  encountered  motivates 
our  recommendation  for  formalizing  SoS  M&S  lU  definition  and 
specification  in  a  SoS  domain. 

“Wait  a  minute... we’re  not  talking  about  the  same  lU?” 

Applying  M&S  to  the  BMDS,  a  SoS,  we  recognized  that 
BMDS  M&S  is  itself  a  SoS  engineering  endeavor.  In  2006,  the 
MDA  established  the  BMDS  M&S  Program  including  a  goal 
of  assessing  BMDS  capabilities  with  end-to-end,  construc¬ 
tive  simulations.^  High-resolution,  “engineering-grade”  M&S 
previously  and  independently  developed  for  Element  program 
acquisitions  (i.e.,  the  Elements’  overarching  I  Us)  comprise  the 
BMDS  simulations  of  Element  interceptors,  sensors  and  battle 
management  interoperating  as  a  BMD  SoS.  At  first,  we  ex¬ 
pected  that  composing  an  acquisition-focused  BMD  SoS  M&S 
from  acquisition-focused  Element  M&S  constituents  should  be 
hard  but  straightforward  and  predictable  work.  We  envisioned 
that  disciplined,  collaborative  requirements  engineering  across 
both  the  BMDS  M&S  and  the  Element  M&S  was  necessary  and 
sufficient  for  successful  implementation  of  the  BMD  SoS  M&S. 
What  we  encountered  were  conflicts  among  the  Element  M&S 
I  Us,  as  well  as  Element  lU  conflicts  with  the  BMDS  M&S  lU. 

•  The  mission  contexts  of  Element  M&S  I  Us  vary  substantially; 
some,  such  as  the  BMDS  Command,  Control,  Battle  Manage¬ 
ment  and  Communications  (C2BMC)  Element,  exist  solely  for 
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a  BMDS  mission,  while  others,  such  as  Aegis  BMD  with  fleet 
defense,  have  standalone  or  additional  non-BMD  missions 

•  Element  M&S  IDs  are  rarely  “Legos™,’’  as  each  Element’s 
acquisition  engineering  M&S  ID  may  be  very  specific  to  an 
independent  Element  program;  e.g.,  enemy  missile  threats  to 
which  an  Element  is  engineered  might  be  very  specific,  and  the 
M&S  ID  will  also  be  as  specific 

•  In  most  cases  the  Element  programs,  before  developing 
their  M&S,  did  not  receive  M&S  composability  requirements  to 
enable  future  BMDS  M&S  ID;  in  result.  Element  M&S  architec¬ 
tures  complicate  integration  and  interoperability;  an  example  is 
organic,  tightly  integrated  Radar  Cross  Section  (RCS)  model¬ 
ing  of  an  enemy  missile  threat  by  two  Elements  that  the  BMDS 
M&S  ID  requires  to  have  a  common,  consistent  RCS  mea¬ 
surement  (e.g.,  adjusted,  of  course,  for  sensor  characteristics, 
viewing  angles,  and  threat  orientation). 

These  kinds  of  M&S  lU  conflicts  embodied  risks  that  too  of¬ 
ten  we  saw  become  programmatic  issues.  Preparing  for  BMDS 
M&S  integration,  the  Element  M&S  developers  undertook 
reengineering  their  simulations  for  interoperation  with  others’ 
simulations;  in  their  original,  standalone  versions,  the  Element 
simulations  represented  the  effects  of  interactions  happening, 
but  not  the  full  interactive  process  (e.g.,  a  BMDS  battle  manager 
function  assigning  a  missile  intercept  to  one  tracking  Element 
versus  another).  Discovery  of  the  interoperability  and  integration 
requirements  was  an  unexpectedly  prolonged  trial-and-error 
process,  and  integration  lead  times  to  prepare  BMDS  assess¬ 
ments  were  neither  predictable  nor  affordably  short  to  sustain 
BMDS  analysts’  desired  work  tempos. 

In  the  early  BMDS  M&S  lU,  the  BMDS  architecture  was  far 
more  loosely  coupled  than  at  present,  and  omitting  some  Element 
interactions  or  common,  consistent  threat  or  environment  model¬ 
ing  did  not  necessarily  thwart  the  overall  BMDS  M&S  lU.  Never¬ 
theless,  root  causes  of  errors  discovered  during  runs-for- record 
often  traced  at  least  in  part  to  previously  unrecognized  lU  conflicts 
among  the  Element  M&S  and  the  BMDS  M&S.  As  the  near-future 
BMDS  architecture  becomes  more  tightly  coupled,  these  kinds  of 
lU-based  errors  become  much  harder  and  costlier  to  correct. 

Like  C4ISR,  planetary  space  missions,  and  many  other  SoS’, 
comprehensive  testing  of  the  BMDS  is  generally  so  unaf¬ 
fordable,  impractical,  unsafe  or  illegal  (by  treaty)  that  M&S  is 
the  only  means  to  provide  estimates  of  the  capabilities  and 
limitations  of  the  SoS.  However,  while  nearly  always  safe  and 
legal,  M&S  must  be  affordable,  practical  and  timely.  Clarifying, 
understanding,  and  aligning  M&S  lUs  mitigates  at  least  some 
cost,  schedule  and  scope  risks  of  BMDS  M&S. 

Emerging  MDA  Practice  for  Specifying  M&S  lU  in 
BMDS  M&S 

An  engineering  process  of  selecting  a  legacy  M&S  applica¬ 
tion/tool  or  developing  a  new  M&S  application/tool  begins  with 
creating  a  clear  statement  of  the  M&S  lU  and  a  description  of 
the  associated  M&S  Capability  Needs  from  the  perspectives 
of  stakeholder  analysts  (see  Section  2  of  [9]).^  For  the  infer¬ 
ences  stakeholders  want  to  draw  about  the  BMDS,  stakeholder 
analysts  need  particular  kinds  of  M&S  outputs,  and  typically 
require  results  from  particular  kinds  of  M&S  runs  or  experimen¬ 


tal  conditions.  These  M&S  Capability  Needs  encompass  the 
set  of  analysis  capabilities  that  M&S  should  enable  in  order  to 
adequately  achieve  its  lU  (e.g.,  “The  BMDS  M&S  shall  provide 
output  X  under  experimental  conditions  Y  to  enable  the  stake¬ 
holder  analyst  to  calculate  BMDS  metric  Z”). 

The  position  of  the  lU  within  the  Systems  Engineering  Re¬ 
quirements  Process  is  shown  in  Figure  1.  The  depicted  process 
pertains  to  both  unitary  systems  and  SoS.  For  both  legacy  and 
new  M&S,  the  stakeholders  are  responsible  to  articulate  a  set 
of  M&S  Capability  Needs  that  comprise  essential  parts  of  the 
M&S  lU.  If  the  stakeholder  who  utilizes  results  of  an  M&S  tool 
misunderstands  what  lU  drove  its  development,  the  stakeholder 
analyst  is  at  risk  of  misconstruing  the  M&S  results. 


Requirements  Engineering 

Elicitation  Process  Highlights 

•  Subdivide  the  stakeholder 
community  into  multiple  user  classes 
that  have  distinct  needs  &  distinct 
roles  in  utilizing  the  product 

•  Typical  Stakeholder  Classes  are: 
Customer,  User,  Developer,  and 

^  Manager 

CO 

^  •  Develop  the  Stakeholder  M&S 

w  I  Intended  Uses  that  will  serve  to 

o 

=* *  provide  context  of  the  Stakeholder 
Needs 


Requirements  Analysis  Step 


Figure  1 :  Role  of  Intended  Use  Specification  within 
M&S  Requirements  Engineering 

MDA  currently  requires  several  parts  for  a  well-defined  M&S 
lU.  From  the  stakeholder  analyst’s  perspective,  an  M&S  lU  is  not 
a  capability,  solution  or  implementation,  but  part  of  a  clear,  com¬ 
plete  analysis  problem  statement.  MDA  is  establishing  a  stan¬ 
dard  lU  specification  that  contains  the  following  components: 

1 .  Title-For  ease  of  communication  and  reference  among 
stakeholders  and  developers 

2.  Description-Five  essential  elements: 

•  Narrative  identification  of  the  analysis  problem 

•  Narrative  description  of  what  stakeholder  analyst  tasks 
or  processes  the  ID  supports 

•  Narrative  enumeration  of  specific  simulation  outputs  the 
stakeholder  analyst  will  use  in  the  analyst’s  processes; 
should  identify  products  or  documents  that  the  ID  has 
inputs  to  or  creates  directly 

•  Narrative  description  of  special  conditions  or  experimental 
designs  under  which  the  simulation  should  run  to  produce 
the  analyst’s  needed  specific  simulation  outputs;  should 
include  any  needed  simulation  calibration  methods  and 
associated  data 

•  Narrative  description  of  “controls  or  governances” 
identifying  documents  or  processes  to  which  the  lU 
conforms,  such  as  stakeholder  test  objectives 
memorandum  or  a  test  concepts  of  operations  (CONORS) 
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3.  Key  Attributes-For  a  specific  M&S  domain,  standard 
aspects  and  values  that  stakeholders  and  developers  agree 
clarify  understanding  about  the  M&S  ID;  for  MDA’s  BMDS 
M&S  ID,  these  include  the  following:'^ 

•  Focus:  From  narrow  consideration  of  a  component 

(e.g.,  specific  radar)  to  broad  scope  of  the  end-to-end  BMDS 

•  Epoch:  Current  or  future  version  of  the  BMDS 
Architecture  represented 

•  Simulation  Type:  Constructive,  Virtual,  Live  [8] 

•  Fidelity:^  Degree  of  simulation  faithfulness 

•  Uncertainty  Quantification:  Methods  for  representing 
uncertainties  and  propagating  them  to  simulation  outcomes 

•  Tactical  Interoperability:  Accuracy  by  which  the  M&S 
environment  recreates  tactical  Element  or  Component 
external  interfaces 

•  Stimulation  Interface:  Level  of  detail  contained  within 
stimulation  data  distributed  through  the  system;  includes 
threat,  modeled  communication  networks,  environment, 
lethality  (interceptor-target  interaction  physics) 

•  Operator  Screens:  Degree  to  which  user  interfaces  can 
provide  an  Operator-in-the-loop  with  a  realistic  training 
or  exercise  experience 

4.  Identified  Stakeholders-Listing  of  stakeholders  who 
either  “own"  the  M&S  lU  or  make  decisions  with  the 
simulation  results 

A  Case  Study  of  Catastrophic  Risk  from 
Ignoring  SoS  M&S  Ills 

The  Crandall  Canyon  Mine  case  study  reveals  how  fatal  con¬ 
sequences  may  result  from  inadequate  consideration  of  M&S 
I  Us  in  safety  engineering. 

In  August  2007,  the  Crandall  Canyon  Mine  in  Utah  col¬ 
lapsed  and  trapped  six  workers.  Three  more  workers  died  in 
an  additional  collapse  during  rescue  operations  that  ultimately 
failed  to  recover  the  original  six  victims’  bodies.  Investigating  the 
disaster,  the  US  Mine  Safety  and  Health  Administration  (MSHA) 
reviewed  not  only  mine  conditions  and  operations  practices,  but 
also  the  engineering  design  of  the  mine  [10].  MSHA  determined 
that  improper  engineering  analysis  with  two  stress  simulations 
was  one  of  the  root  causes  of  the  collapses  killing  both  the  min¬ 
ers  and  the  rescuers. 

Mine  engineering  analysis  considers  both  geologic  condi¬ 
tions  and  mining  methods.  The  Crandall  Canyon  Mine  employed 
methods  of  “longwall  mining”  and  “retreat  mining”  not  only 
to  maximize  coal  recovery,  but  also  to  ensure  mine  structural 
integrity  for  the  safety  of  workers  and  equipment.  As  longwall 
mining  proceeds  through  coal  beds,  pillars  of  valuable  coal  left 
by  mining  operations  support  the  roof  in  the  mined  space.  When 
advance  through  the  space  completes,  retreat  mining  involves 
partial  or  complete  removal  of  some  pillars  as  workers  withdraw 
equipment  back  from  the  mined  space.  While  pillar  recovery  may 
trigger  some  roof  collapse,  proper  retreat  mining  ensures  that 
roof  collapse  occurs  safely  and  only  in  the  immediate  area  of  a 
pillar  being  extracted.  Mine  design  analysis  considers  such  fac¬ 
tors  as  the  mechanical  properties  of  the  pillar  material,  the  depth 
of  the  mining  space  and  the  condition  of  the  prospective  roof  to 


establish  the  needed  size  and  spacing  of  pillars  for  productive 
but  safe  mining. 

MSHA  found  that  undersized  pillars  contributed  significantly 
to  the  Crandall  Canyon  Mine  collapse.  As  retreat  mining  pro¬ 
ceeded,  excessive  rising  stress  on  remaining  pillars  finally  trig¬ 
gered  one  pillar  failure  that  started  a  ripple  of  load  shocks  over- 
stressing  and  collapsing  other  pillars.  MSHA  focused  specifically 
on  the  use  of  two  mine  engineering  simulations,  “Stress  and 
Displacement  Calculations”  (LaModel)  and  “Analysis  of  Retreat 
Mining  Pillar  Stability”  (ARM PS).  While  MSHA  agreed  with  the 
suitability  of  both  models  for  the  mine  engineering  lU,  MSHA 
found  that  the  Crandall  Canyon  Mine’s  engineering  contractor 
failed  to  apply  LaModel  and  ARMPS  together  Q.e.,  effectively  as 
a  SoS  M&S)  in  accordance  with  their  M&S  I  Us,  which  required 
their  initial  calibration  with  the  same  real-world  geologic  data 
from  the  Crandall  Canyon  Mine. 

This  case  study  provides  a  sobering  lesson  that  the  associ¬ 
ated  data  and  stakeholder  analyst  processes  are  an  essential 
part  of  a  SoS  M&S  lU,  and  they  must  be  applied  consistently 
to  the  M&S  components  involved  in  the  SoS  M&S.  For  large, 
complex  SoS’  like  C4ISR  systems  or  the  BMDS,  document-cen¬ 
tric  M&S  lU  analysis  and  specification  rely  strongly  on  systems 
engineers’  broad  understanding  of  the  entire  SoS  scope.  The 
case  study  shows  how  engineers  may  fail  to  specify  and  apply 
an  M&S  lU  for  even  a  much  narrower  scope  than  the  BMDS. 

The  following  section  outlines  MDA’s  M&S  engineering  initia¬ 
tives  to  increase  the  reliability  and  timeliness  of  SoS  M&S  lU 
analysis  and  specification  through  automation. 

A  Hopeful  Future:  Formalized  M&S  Ills  for  Model- 
Based  Systems  Engineering 

MDA’s  BMDS  M&S  Program  plans  to  update  and  incorporate 
an  M&S  lU  specification  into  Model-Based  Systems  Engineering 
(MBSE)  [1 2]  of  MDA’s  BMDS  M&S.  Implementation  of  MBSE 
for  BMDS  M&S  represents  a  transition  from  document-based 
systems  engineering  to  an  integrated  Systems  Modeling  Lan¬ 
guage  (SysML)  models  [13]  of  requirements,  structure,  behavior 
and  parametrics  (algorithms,  quantities-of-interest,  units-of- 
measure,  etc.).  MDA  is  currently  developing  the  MBSE  infra¬ 
structure  of  engineering  processes,  methods,  standards,  training, 
staffs  and  tools  for  Model-Based  SoS  Engineering  (MBSoSE) 
of  BMDS  M&S.  Clear,  complete  M&S  I  Us  are  essential  to  sus¬ 
tained  MBSoSE  of  BMDS  M&S  to  support  decisions  about  the 
best  M&S  components  to  use  in  standalone  or  compositions  to 
fulfill  stakeholder  needs. 

Some  benefits  MDA  anticipates  from  MBSoSE  inciuding 
M&S  I  Us  are  the  foiiowing: 

•  A  repository  of  M&S  lU  information  updated  as 
M&S  constituents  evolve 

•  Automated  traceability  and  allocation  of  M&S  lU  information 
to  stakeholder  requirements;  M&S  logical  standalone  or 
composition  design;  M&S  behavior;  and  M&S  parametrics 

•  Automated  design  verification 

•  Automated  detection  and  analysis  of  M&S  lU  errors, 
contradictions  or  gaps  in  addressing  stakeholder  needs, 
derived  requirements  and  logical  design 
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•  Clear,  consistent,  traceable,  measurable,  testable 

requirements  allocated  to  the  Element  and  overall  BMDS 
M&S  developer  organizations  (e.g.,  to  put  on  contract) 
Complementing  MDA’s  transition  to  MBSoSE  with  M&S  I  Us 
are  changes  in  BMDS  M&S  governance  and  culture  that  are 
not  yet  fully  defined.  Realizing  some  of  the  above  benefits  also 
requires  evolution  in  MBSE  tool  technology  and  the  SysML  lan¬ 
guage.®  We  anticipate  those  technical  changes  will  occur  concur¬ 
rently  with  MDA’s  BMDS  M&S  governance  and  culture  evolution. 

In  the  future  we  hope  to  report  on  best  practices  and  lessons 
learned  from  MDAs  transition  to  MBSoSE  of  BMDS  M&S. 

Summary 

MDA  has  formalized  specification  of  BMDS  M&S  lU  to 
mitigate  programmatic  risks  and  to  improve  affordability  and 
outcomes  of  M&S-based  acquisition  activities.  Lessons  learned 
in  BMDS  M&S  informed  MDAs  specification  of  a  BMDS  M&S 
lU  standard  focused  on  stakeholder  analysts  as  the  consumer 
of  M&S  results.  Disciplined  use  of  MDAs  SoS  M&S  lU  approach 
helps  avoid  costly  or  even  catastrophic  risks  of  misapplying 
M&S.  Though  the  original  SoS  M&S  lU  specification  is  docu¬ 
ment-centric,  MDA  anticipates  its  transition  to  future  model¬ 
centric  processes  with  MBSoSE  automation  increasing  both 
affordability  and  the  tempo  of  M&S-based  acquisition  activities.^ 
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Homeland 

Security 


The  Department  of  Homeland  Security,  Office  of  Cybersecurity  and 
Communications  (CS&C)  is  responsible  for  enhancing  the  security, 
resiliency,  and  reliability  of  the  Nation's  cyber  and  communications 
infrastructure  and  actively  engages  the  public  and  private  sectors  as 
well  as  international  partners  to  prepare  for,  prevent,  and  respond  to 
catastrophic  incidents  that  could  degrade  or  overwhelm  these  strategic 
assets.  CS&C  seeks  dynamic  individuals  to  fill  critical  positions  in: 


•  Cyber  Incident  Response 

•  Cyber  Risk  and  Strategic  Analysis 

•  Networks  and  Systems  Engineering 

•  Computer  &  Electronic 
Engineering 


Digital  Eorensics 
Telecommunications  Assurance 
Program  Management  and  Analysis 
Vulnerability  Detection  and 
Assessment 


To  learn  more  about  the  DHS,  Office  of  Cybersecurity  and 
Communications,  go  to  www.dhs.gov/cybercareers.  To  apply  for  a 
vacant  position  please  go  to  www.usajobs.gov  or  visit  us  at 
www.DHS.gov. 
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1.  “Point,”  “line”  and  “plane”  are  examples  of  a  primitive  notion,  a  concept  undefined 
by  previously  defined  concepts,  and  often  motivated  by  intuition,  common  sense  or 
everyday  experience  [7].  We  find  M&S  practitioners  inclined  to  specify  I  Us  as 
“primitive  notions”  about  which  all  M&S  stakeholders  should  agree.  In  System- 
of-Systems  (SoS)  M&S  engineering,  diverse  stakeholders  using  the  same  words  with 
different  meanings  can  disagree  about  an  M&S  lU  specification  without  recognizing 
any  disagreement.  Thus,  for  success  of  M&S  SoS  engineering,  we  argue  that  M&S 
“lU”  in  SoS  cannot  be  a  primitive  notion  like  those  basic  ideas  of  geometry. 

2.  A  “constructive  simulation”  is  a  pure  software  implementation  of  a  model  of  the 
system  of  interest  of  “real”  (or  envisioned)  people,  hardware,  software,  other 
facilities,  inputs,  outputs  and  processes  [8].  While  real  simulation  operators  stimulate 
(i.e.,  make  inputs,  initiate  runs)  to  such  simulations,  the  operators  are  not  otherwise 
involved  in  determining  the  simulation  outputs  (e.g.,  operators  do  not  interact  as 
“players”  or  “trainees”  with  the  simulation  during  a  run).  Constructive  simulations 
typically  support  acquisition  engineering  activities. 

3.  In  DoD  practice,  stakeholder  analysts  are  typically  the  users  of  the  results  of 
simulation  runs  (experiments).  Analysts  are  often  not  M&S  developers  and 
maintainers.  In  the  experience  of  one  of  the  present  authors,  commercial  practice 
tends  to  combine  the  roles  of  stakeholder  analyst  and  M&S  developer.  Commercial 
practice  is  also  infrequently  concerned  with  simulation  reuse  or  simulation 
compositions  for  SoS  engineering. 

4.  M  DA  has  not  publicly  released  Key  Attribute  values  for  M&S  I U. 

5.  “The  degree  to  which  a  model  or  simulation  reproduces  the  state  and  behavior  of  a 
real  world  object  or  the  perception  of  a  real  world  object,  feature,  condition,  or  chosen 
standard  in  a  measurable  or  perceivable  manner;  a  measure  of  the  realism  of  a  model 
or  simulation;  faithfulness”  [11]. 

6.  “Pragmatics”  is  a  term  used  in  formal  logics  of  Dntologies  and  the  Semantic  Web. 
Both  Zeigler,  et  al  [14],  and  Tolk,  et  al  [15],  provide  a  formal  mathematical  definition 
of  “lU”  not  as  a  “primitive  notion,”  but  as  a  pragmatic  in  terms  of  other  concepts 
from  Dntologies.  The  benefit  of  defining  an  I U  as  a  mathematical  pragmatic  is 
machine  readability  (e.g.,  in  a  future,  more  formal  SysML  grammar,  or  with  the  Web 
Dntology  Language,  DWL)  and  machine  decidability  about  the  congruence  of  an  M&S 
lU  to  stakeholder  needs  (e.g.,  in  SysML  design  verification  of  an  M&S  composition). 

The  future  MBSE  capabilities  will  slash  the  lead  time  for  SoS  M&S  systems  engineering 
and  integration,  and  increase  the  tempo  of  M&S-based  analyses  of  large,  complex  SoSs. 
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